The Basics of Architectural Thinking

Many of us think of architectural thinking as just ‘thinking about the architecture’ but it is much more than that. It is seeing things with an architectural eye. It is a brutal truth about architecture that everything in architecture is a trade-off hence just understanding the how of a system is not enough, the most important thing is to understand the why behind the decisions made by an architect. 

This gives us a wide understanding of the trade-offs made by an architect and the priorities of a system.

There are 4 main aspects of thinking like an architect

Architecture versus Design

It is quite confusing to understand the difference between Architecture and Design, in fact I was not aware that there is a difference at all. Thinking like an architect is knowing the difference between architecture and design and seeing how the two integrate closely to form solutions to business and technical problems.

Architecture is the structure of the system whereas design comes into play when developers implement the architecture and the functionalities the system is designed to deliver. This is a traditional process.

An architecture is responsible for analysing business requirements to extract and define the architectural characteristics. The artefacts created from this are handed over to the development team for creating class diagrams for each component, creating UI and developing source code. There are several issues with the traditional responsibility model, specifically the difference between what the architect thinks can be achieved and what the developer experiences as not achievable.

As an evolution of this, developers and architects have started working together in order to communicate faster and provide better feedback, this allows architects to be more aggressive and experimental with their approach.

In this scenario, you might say "So where does architecture end and design begin?" well, it doesn't, they are both part of the circle of life within a software project and must always be kept in synchronisation with each other in order to succeed.

Technical Breadth

The scope of technological detail differs between developers and architects. Unlike a developer, an architect does not need to know a concept in detail, it is important for an architect to have technical breadth instead of technical depth, since it is important for an architect to know a wide range of technologies, frameworks and tools to choose the ones which are best suitable to achieve goals of a system in the best possible way.

Analysing Trade-Offs

As I said in the beginning of this article, everything is architecture is a trade-off. Thinking like an architect is all about seeing trade-offs in every solution, technical or otherwise, and analysing those trade offs to determine what is the best solution.

There are no right or wrong answers in architecture - only trade offs.

This way there are always multiple solutions to a problem but choosing the most suitable one, depending on the main objective of the problem is what provides us with the best solution.

For example, in a system where a single piece of information needs to be delivered to 3 components, it is a choice between using a notification service or a queueing service, while using a notification service we only need the end components to subscribe to a single topic whereas in a queueing service we need to create a separate queue for every end component, this increases costs and also the number of components to be considered during a system update. But if we do use a notification system, it does mean that the same piece of information is being delivered to every component which is a security risk, with queues you can control the amount of information being shared. Talking about security, in a notification based implementation, the producer in itself is not aware of the components consuming the information generated, but in a queueing system, the end component is always visible and known.

Understanding Business Drivers

In the example above we discussed the trade offs involved in designing a simple system, but which is the best possible solution for our problem? This question is answered by analysing the business drivers, environment and host of other factors.

Thinking like an architect is understanding the business drivers that are required for the success of the system and translating those requirements into architectural characteristics (scalability, performance and availability). This requires the architect to have knowledge about the business domain. Architect needs to identify and understand the business relationships of a system to ensure that all the needs of the system are met.